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@ Computer integrated manufacturing rework apparatus and method. 

(57) A manufacturing rework station is integrated 
with a computer. A repair cell (300) program 
running on the computer functions as an inter- 
face between the rework station operator, one 
or more databases (310, 311, 312, 313, 314), and 
one or more knowledge bases (320). The repair 
cell provides the operator with an easy to use 
graphical environment which aids in the diag- 
nosis and repair of defects. The cell simul- 
taneously provides operator assistance, records 
operator activity, and collects new knowledge 
when the problem under analysis was previ- 
ously unknown. 

The databases contain manufacturing history 
for each individual article. The operator will 
input the serial number of the article with a 
bar-code reader (113), causing the program to 
fetch the record of the article. The computer 
generates an image article on the display (110). 
The operator may select a component of the 
article with a lightpen (112). In response to the 
selection of a component, the computer dis- 
plays the possible diagnoses and repair actions 
associated with that component, together with 
a figure of merit. The operator may also invoke 
an expert consolation mode, in which the com- 
puter suggests a diagnosis or requests ad- 
ditional information while searching a directed 
graph. When a diagnosis is made, the computer 
automatically updates its databases. A plant 
monitoring and reporting program has access 
to the diagnostic statistics, and can generate a 
warning when a particular defect exceeds a 
limit, or generate defect reports on request. 
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The present invention relates to computer inte- 
grated manufacturing, and in particular to a computer 
system which supports the rework of manufactured 
articles. 

Today, we are surrounded by many useful articles 
of human manufacture. Historically, manufactured 
articles have grown increasingly complex, and there 
is every reason to believe they will continue to do so 
in the future. In order to cope with the increasing com- 
plexity of manufactured articles, the processes by 
which these articles are made must continually be 
made more efficient. 

In recent decades there has been a spectacular 
growth in machines that use and process information. 
This phenomenon has sometimes been referred to as 
the "second industrial revolution". Just as the steam 
engine was the symbol and driving force of the first 
industrial revolution, the digital electronic computer 
has become the symbol and driving force of the sec- 
ond. 

With this spectacular growth in the field of infor- 
mation processing, it was inevitable that computers 
would be enlisted in the struggle to make manufactur- 
ing processes more efficient. The use of computers to 
improve manufacturing processes has become a field 
in itself, known as computer integrated manufacturing 
(CIM). There are today hundreds of uses for compu- 
ters in manufacturing, and the number of new uses is 
growing. However, CIM is still in its infancy. There are 
many manufacturing processes to which it has yet to 
be applied. 

Many manufacturing processes involving com- 
plex articles must make provision for rework. Rework 
is the process of correcting the defects in a manufac- 
tured article, after it has completed the normal stages 
of a manufacturing process. It is not uncommon, for 
example, for an article to contain hundreds of compo- 
nent parts. When the article is assembled, it will be 
subjected to inspection and functional testing, to 
verify that the article is correctly manufactured. 
Depending on the complexity, inspection and func- 
tional testing may be performed at various stages of 
manufacture and on different levels of assemblies. A 
certain percentage of articles will fail this testing. In 
the event of failure, the article will either be scrapped 
or reworked. Scrapping a defective article is feasible 
in the case of simple, inexpensive wares, but it doesn't 
make economic sense in the case of more complex, 
expensive assemblies. For example, an automobile 
after final assembly and inspection may prove to have 
a defective wind-shield wiper. In this case, it does not 
make sense to scrap the automobile. The manufac- 
turer will instead correct the problem by rework, i.e. 
repair or replacement of the defective component 

Rework tends to be a very specialized process. 
One common thread among existing CIM applications 
is that they apply to the mainline manufacturing pro- 
cess, rather than the rework process. This is so 



because mainline processes are predictable. The 
computer knows what stage of the process comes 
next, what component parts must be added to the 
assembly during this stage, which manufacturing sta- 

5 tions have the capabil ity to perform the work, how long 
the work should take, etc. Rework, on the other hand, 
is inherently unpredictable. There is no way to know 
in advance how long it will take to diagnose a problem, 
or what components will require repair or replace- 
to ment. Because diagnosis of certain problems in not 
an exact science, the initial diagnosis is frequently 
wrong, and the reworked article will fail testing even 
after some of the components are replaced. The arti- 
cle may go through several passes of diagnosis and 

15 repair in rework stations before the problem is correc- 
ted. For these reasons, rework is generally a manual 
process. Even in a computer automated factory envi- 
ronment, an article requiring rework is usually 
removed from the normal manufacturing stream, and 

20 set aside in a manual rework station. Here, a person 
with sufficient expertise will diagnose the problem, 
and either correct it himself or send the article to some 
other work station for repair. When the problem has 
been corrected, the article must be re-tested, and 

25 eventually re-inserted into the manufacturing stream. 

There are additional consequences of this imba- 
lance between an automated mainline process and 
manual rework. No matter how good the process con- 
trol, defects can be introduced from time to time into 

30 the mainline process. For example, a batch of compo- 
nent parts from a supplier may have a high rate of 
defects, a robotic arm may be misaligned, a tempera- 
ture control unit may malfunction, etc. If the resultant 
defects in the manufactured products are not discov- 

35 ered until they are diagnosed during manual rework, 
it could be days or weeks before someone realizes 
that the same defect is repeatedly appearing, and 
tracks that defect down to the offending cause. The 
automated line could in the meantime produce large 

40 numbers of defective articles. 

Prior art computer integrated manufacturing 
applications have focused on the mainline manufac- 
turing process. For example, computers have been 
used in manufacturing to track inventories, to direct 

45 the flow of the manufactured articles among different 
manufacturing work stations, to control robotic equip- 
ment, to schedule critical equipment and processes, 
and for many other things. These systems have con- 
siderably increased the productivity and efficiency of 

50 the mainline process. However, these systems gener- 
ally do not address the problems of rework. 

In a manufacturing facility with a low level of auto- 
mation, rework consumes a relatively small proportion 
of the facility's total human resources. However, as 

55 mainline manufacturing processes become increas- 
ingly automated, and integrated with computer con- 
trol, the proportion of human resources devoted to the 
manual rework process grows ever larger. What is 
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worse, the diagnostic and specialized nature of 
rework demands the more skilled members of the 
work force. With the rising complexity of manufac- 
tured articles, we can expect that the possible causes 
of failure and the difficulty of diagnosing them will s 
increase. All of these factors foretell a day when "auto- 
mated" factories will become bogged down in their 
own rework. Of course, such a scenario need not 
occur, if the mind of man can devise more efficient 
mechanisms for performing rework. Such is the thrust 10 
of the invention disclosed herein. 

It is therefore an object of the present invention to 
provide an enhanced method and apparatus for per- 
forming rework of manufactured articles. 

Another object of this invention is to provide more 15 
accurate diagnosis of faults in a manufacturing rework 
process. 

Another object of this invention is to reduce the 
time required to rework manufactured articles. 

Another object of this invention is to reduce the 20 
cost associated with reworking manufactured articles. 

Another object of this invention is to reduce the 
level of expertise required of persons performing 
rework of manufactured articles. 

Another object of this invention is to provide an 25 
enhanced method and apparatus whereby shortcom- 
ings in a mainline manufacturing process may be 
identified. 

Another object of this invention is to provide an 
earlier warning of shortcomings in a mainline man- 30 
ufa ctu ring process. 

Another object of this invention is to provide an 
enhanced method and apparatus forgathering statis- 
tics concerning the causes of failures in manufactured 
articles. 35 

Another object of this invention is to reduce the 
cost of gathering statistics concerning the causes of 
failures in manufactured articles. 

Another object of this invention is to increase the 
speed with which statistics concerning the causes of 40 
failures in manufactured articles may be obtained. 

A manufacturing rework station is integrated with 
a computer according to this invention. The rework 
station comprises a computer having access to one or 
more databases, a computer display connected to the 45 
computer, and input/output means for the rework sta- 
tion operator. A repair cell application program run- 
ning on the computer functions as an interface 
mechanism between the rework station operator, one 
or more databases, and (optionally) one or more so 
knowledge bases (expert systems). Its purpose is to 
provide the operator with an easy to use graphical 
environment which aids in the diagnosis and repair of 
defects in the manufactured article. This ability is pro- 
vided through the object orientation of the interface. In 55 
the preferred embodiment, this mechanism simul- 
taneously provides operator assistance, records 
operator activity, and collects new knowledge when 
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the problem under analysis was previously unknown, 
although some of these aspects of the invention may 
be implemented independently. The activity monitor- 
ing and data acquisition is passive, requiring no speci- 
fic actions on the operator's part. The intent is to 
create a user interface which aids a knowledge base 
in maintaining itself, and which may be consulted by 
the operator when he is unsure how to proceed. 

In the preferred embodiment, one or more of the 
databases contain manufacturing history for each 
individual article. These databases will contain a com- 
plete list of all repair actions performed on the article, 
as well as the failure symptoms that were exhibited by 
the article during testing. Upon arrival of the article at 
a rework station, the operator will input the serial num- 
ber of the article with a bar-code reader, identifying 
the type of article to the repair cell program and caus- 
ing the program to fetch the historical record of the 
article. The computer will generate a graphical repre- 
sentation of the article on the display screen. The 
operator may select a component of the article with a 
cursor pointing device, such as a mouse or lightpen. 
Each component is associated with a list of possible 
diagnoses affecting that component. In response to 
the selection of a component, the computer displays 
the possible diagnoses and repair actions associated 
with that component. The operator may also invoke 
either of two consultation modes. In one mode, the 
computer displays a figure of merit for each diagnosis, 
representing the relative frequency that the indicated 
repair action has cured similar defect symptoms in the 
past. In the second consultation mode, an expert sys- 
tem follows a directed graph of decision points to 
arrive at a diagnosis. The diagnosis is based on 
defect symptoms exhibited during testing of the arti- 
cle, the past frequency of repair actions, the history of 
repair actions taken with respect to the particular arti- 
cle, and rules of guidance derived from engineering 
personnel. When the operator has determined a diag- 
nosis, he selects one of the listed items and performs 
the repair action. In the alternative, the actual repair 
could be performed at a different work station, after 
the diagnosis has been made. When a diagnosis and 
repair action is selected, the computer automatically 
updates its databases containing the repair history of 
the individual article as well as the diagnostic statis- 
tics for the manufacturing line. 

In the preferred embodiment, a plant monitoring 
and reporting program has access to the diagnostic 
statistics. When a particular diagnosis shows 
increased frequency, the program will generate a 
warning message to the plant operators. The datab- 
ases not only contain repair history data, but the iden- 
tity of all manufacturing stations performing work on 
that part. With this data, the monitoring and reporting 
program can determine which station is responsible 
for a rise in defects. The monitoring and reporting pro- 
gram can also issue general reports of plant perform- 
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ance in response to a request from the operator. 
Fig. 1 shows the major components of a computer 
integrated rework station according to the prefer- 
red embodiment of this invention; 
Fig. 2 shows the local area network environment 
of a computer integrated rework station according 
to the preferred embodiment of this invention; 
Fig. 3 shows the operating environment of the 
repair cell application program according to the 
preferred embodiment; 

Fig. 4 shows the structure of a typical card des- 
criptive file according to the preferred embodi- 
ment; 

Fig. 5 shows the coordinate system used to 
define card and component images in the prefer- 
red embodiment; 

Fig. 6 shows the structure of the test result datab- 
ases in the preferred embodiment; 
Fig. 7 shows the structure of the repair 
action/defect databases in the preferred embodi- 
ment; 

Fig. 8 shows the structure of the defect code 
databases in the preferred embodiment; 
Fig. 9 is a block diagram of the major steps in the 
manufacturing environment according to the pre- 
ferred embodiment; 

Fig. 10 is a flowchart of the operation of a typical 
rework station according to the preferred embodi- 
ment. 

Figure 1 shows a typical rework station 100 
according to the preferred embodiment of the present 
invention. In the embodiment described herein, the 
manufactured article is an electronic circuit card 
assembly 101. However, it should be understood that 
this invention is applicable to the rework of almost any 
article of manufacture, and is not limited to electronic 
circuit card assemblies. 

A computer generated display means, which in 
this embodiment is a cathode ray tube display 110, 
provides graphical and textual information to the 
operator. Display 110 is coupled to local computer 
114. Keyboard 111, light pen 112, and bar code 
reader 113 are also coupled to local computer 114. 
These devices provide input information to the com- 
puter, it being understood that other input means 
could be used in alternative embodiments. Local com- 
puter 114 is connected via communications cable 115 
to a local area network. In the preferred embodiment, 
local computer 1 14 is an IBM Personal System/2 com- 
puter, which includes a local disk drive storage 
device, it being understood that other computers 
could be used. 

Card assembly 101 comprises a plurality of elec- 
tronic components 103, 104, 105, 106, 107, e.g. logic 
modules, memory modules, resistors, diodes, con- 
nectors, etc. Card assembly 101 also includes a bar 
coded label 102, capable of being read by bar code 
reader 113. 
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In the preferred embodiment, diagnosis and 
repair are performed at a single rework station, so that 
the rework station also comprises soldering tool 120, 
lighted magnifying glass 121, and other miscel- 

5 laneous tools 122 required to perform repairs. In an 
alternative embodiment, diagnosis and repair could 
be performed at separate work stations. The rework 
station optionally includes test device 123, connected 
to the card under rework and to local computer 114. 

10 Test device 123 is capable of running diagnostic logic 
tests on card 101 in response to commands received 
from local computer 1 14. 

Local area network (LAN) 200 is shown in Figure 
2. The local computer 1 14 of one or more rework sta- 
ts tions 100 are connected to LAN 200. Additionally, 
computer terminals at one or more test stations 21 0, 
211 and at one or more assembly stations on the man- 
ufacturing line 212, 213, 214 are connected to the 
LAN. Engineering design system 215, plant manager 

20 station 216 and resource/database server 220 are 
also connected to LAN 200. Engineering design sys- 
tem 215 is a computer system used by engineering 
personnel to design the cards being manufactured. 
Plant manager 216 is a station used by plant manage- 

25 ment personnel for monitoring overall performance of 
the manufacturing facility. Resource/database server 
220 controls access to one or more data storage 
devices 221 , 222, 223, which in the preferred embo- 
diment are rotating magnetic disk drives. The data 

30 storage devices are used to store databases required 
by local computer 114 of the rework station, as well 
as other areas of the system. Server 220 will some- 
times act as a resource server, accessing database 
information and manipulating it prior to sending it out 

35 over LAN 200; at other times, server 220 is strictly a 
database server, returning unprocessed database 
information in response to a request. Server 220 also 
contains defect monitor 224. Monitor 224 is an appli- 
cation program which monitors repair actions and 

40 generates warning messages when defects rise 
above a critical level. While Fig. 2 shows two rework 
stations, two test stations, and three manufacturing 
stations, a single engineering design system, plant 
manager, and resource/database server, it should be 

45 understood that the actual number of nodes that may 
be connected to LAN 200 is variable, and that nodes 
of other type may be connected to the LAN. 

A repair cell application program 300 resides and 
executes on local computer 114. As shown in Figure 

so 3, repair cell 300 is an electronic interface mechanism 
between the rework station operator, one or more 
databases 310-314, and one or more knowledge 
bases (expert systems) 320. Its purpose is to provide 
the operator with an easy to use graphical environ- 

55 ment which aids in the diagnosis and repair of defects 
in the card assembly. Repair cell 300 may invoke 
expert system inferencing engine 304 for assistance 
in diagnosing card assembly defects. In this em bod i- 

4 
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ment, repair cell 300 has access to card component 
database 310, set of bitmap images 311, test result 
databases 312, repair action/defect databases 313, 
and defect code databases 314. It also can access 
diagnostic knowledge base 320. Card component 5 
database 310 contains bill of material information des- 
cribing the card assembly and its component parts. 
Bitmap images 31 1 contain graphical images of com- 
ponents included in the card assembly, which are 
pieced together to form a composite image of the 10 
assembly. Test results databases 312 contain the 
complete test results and failure symptoms for each 
individual card. Repair action/defect databases 313 
contain the history of all repair actions, and the history 
of repair actions later judged successful (hence indi- 15 
cative of correct diagnosis). Defect code databases 
314 contain data relating each sub-object type to the 
possible diagnoses and repair actions applicable to 
that type. Diagnostic knowledge base 320 is a 
knowledge base of production rules, established in 20 
consultation with engineering personnel, to assist in 
diagnosing defect conditions. The rules in diagnostic 
knowledge base 320 form the knowledge base 
required by expert system inferencing engine 304 in 
making inferences concerning card defects. In this 25 
embodiment, repair cell 300 and expert system 
inferencing engine 304 reside on local computer 114. 
The master copy of databases 310-314 and 
knowledge base 320 reside on storage devices 221, 
222, 223 accessible through database server 220; a 30 
local copy of all or portions of these databases may 
be kept on local computer 1 14 to improve perform- 
ance. 

Repair cell 300 includes a graphical image pro- 
cedure 301 and a selection decode procedure 302. 35 
These two procedures form the centerpiece of the 
operator interface. Graphical image procedure 301 
builds an image of the card assembly under diag- 
nosis, and displays it on display 110. The image is 
constructed from objects and sub-objects stored in 40 
card component database 310. This image may be a 
single entity, or (most often) a mosaic or composite 
image of numerous sub-objects. These sub-objects 
may be of related or unrelated types. Selection 
decode procedure 302 permits the user to select one 45 
of the components of the card assembly by pointing 
to it with light pen 112. The procedure decodes the 
screen location and determines which sub-object is 
being displayed at that location. 

Card component database 310 contains a 50 
plurality of card descriptive files, each of which des- 
cribes a type of card assembly. Figure 4 shows the 
structure of a typical card descriptive file 400. File 400 
is named according to the part number of the card 
assembly, each part number decoding to some 55 
unique file name. This permits accessing of the card 
component file for a part number once the part num- 
ber is known. 
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Card component file 400 contains a single header 
entry 401 defining the global parameters of the card, 
and (optionally) one or more sub-object entries 
402,403,404,405 defining the type and location of 
components and features on the card. The fields of 
the sub-object entries 420-429 shown in Fig. 4 are 
defined below. Graphical image procedure 301 con- 
structs a graphical image by building a base card from 
the header, and adding features specified by the sub- 
object entries. Sub-object entries are not necessarily 
true components, but may be merely image features 
which are incorporated into the image of the card 
assembly, to assist in visual identification. In the pre- 
ferred embodiment, the engineering design system 
used by engineering personnel to design the card 
assembly is coupled to local area network 200. The 
bill of material for each assembly are contained in the 
engineering design system. An application program 
resident in the engineering design system creates 
card component file 400 from the bill of materials. 
Thus the generation and maintenance of card images 
is fully automated. 

Card header entry 401 defines the size and part 
number of the card, as shown in Fig. 4. It consists of 
part number field 410 and card extent fields 411-416. 
Card extent fields 411-416 define two nested rec- 
tangles as shown in Fig. 5. Image extent rectangle 
501 is the outer rectangle; it defines the space avail- 
able for the mapping of bitmap images onto the card. 
Raw card extent rectangle 502 is the inner rectangle, 
defining the size of the physical raw card. Image 
extent rectangle 501 is larger than raw card extent 
rectangle 502 because it is possible for some compo- 
nents (e.g. connectors) to extend over the edge of the 
card. Card extent fields 411-416 define these rec- 
tangles in an X-Y coordinate system, in which the 
lower left corner of image extent rectangle 501 is the 
origin. Extent fields 413 and 41 1 are the "X" and "Y" 
coordinates, respectively, of the lower left comer of 
raw card extent rectangle 502. Extent fields 416 and 
415 are the "X M and "Y" coordinates, respectively, of 
the upper right corner of raw card extent rectangle 
502. Extent fields 414 and 412 are the "X" and "Y" 
coordinates, respectively of the upper right corner of 
image extent rectangle 501 . 

Each sub-object entry 402-405 is associated with 
a color bitmap representation of the component or 
feature. For example, a logic module may be a rec- 
tangle with an orientation notch and pins protruding 
from the sides; the pins or notch may be of different 
color than the base rectangle to assist in visual iden- 
tification. A series of application programs resident in 
the engineering design system manipulates the card 
bill of material first into a descriptive bitmap place- 
ment and extent list and secondly into a composite bit- 
map for the assembly. These finished bitmaps are 
compressed to minimize access time across local 
area network 200 and stored in bitmap database 31 3. 
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The bitmaps are dynamically decompressed when 
received by local computer 114. 

Sub-object image bitmap identifier field 420 is a 
numeric identifier of the bitmap that will be used to 
represent the sub-object when the composite image 5 
is created. This identifier is itself encoded, with the 
least significant digit representing the orientation at 
which to place this instance of the bitmap. The coding 
scheme is '0* = 0 degrees, T = 90 degrees, etc. 
which allows for the four cardinal orientations. This is 10 
sufficiently flexible for use in card assemblies. 

Min/max sub-object extent fields 421, 422, 423, 
424 define the minimum and maximum "X" and "Y" 
extent of the component or feature. The sub-object is 
described as occupying a rectangular extent area 503 15 
in the two-dimensional plane of the card assembly. 
These extent fields define the limits of rectangular 
area 503 by specifying the "X" and T coordinates of 
two opposite corners of the component, as shown in 
Fig. 5. More complex sub-objects would obviously 20 
require a more involved set of limit description num- 
bers, possibly including a third dimension and/or com- 
plex polygons sub-object domain descriptions. 

Front/back indicator 425 is a flag used in this two- 
dimensional implementation to differentiate sub-ob- 25 
jects on the front side of the circuit card from those on 
the back. It is common in the design of circuit cards 
to place components on both sides of the card. 

Sub-object location identifier 426 defines the sub- 
object location in the nomenclature of the Engineering 30 
Design System. It is included in the sub-object record 
to allow repair actions collected by the system to be 
reported in a compatible format. This information is 
redundant, since an algorithm could be derived to 
transform sub-object extent fields 421-424 into this 35 
format. Its existence is justified by performance con- 
siderations. 

Sub-object part number 427 is the part number of 
the component. The repair cell can display this part 
number to the operator, allowing quick access to the 40 
spare parts inventory, which is keyed by part number. 

Selectable sub-object flag 428 is used to differen- 
tiate true component sub-objects from other included 
bitmaps which are merely included detail or 'window 
dressing 1 . Selection decode procedure 302 checks 45 
this flag and will not allow selection of items which are 
not true components. 

Sub-object type field 429 defines the diagnoses 
and repair actions associated with the component. 
This field is used to inform selection decode pro- so 
cedure 302 which object type is to receive messages 
if this sub-object is selected by the operator. The sub- 
object type is independent of the representative bit- 
map image used, allowing functionally similar 
sub-objects which are visually different to reuse the 55 
same object support code. This drastically reduces 
the need to create new objects, since most new sub- 
objects are merely new instances of pre-existing sub- 

6 



object types. 

Test results databases 312 comprise three sepa- 
rate database files containing failure symptom infor- 
mation, as shown in Fig. 6. Card process result file 

601 contains an entry for each test performed on each 
individual card, identifying the test, the test station, 
the individual card, and the result (pass/fail). If the 
result of the test was failure, additional information is 
contained in two more files. Environmental data table 

602 contains environmental information concerning 
test conditions. Extended failure information log 603 
contains the actual failure symptoms. 

Figure 6 shows typical entries in test result datab- 
ases 312. Card process result file entry 610 com- 
prises card part number 61 1 , card serial number 61 2, 
test station identifier 613, test operator identifier 614, 
machine group of test station 615, test result 616, 
transaction identifier 617, and time/date stamp 618. 
Test result field 616 contains either "P" (pass), "F" 
(fail) or W R" (passed on retry). Transaction identifier 
617 is an arbitrary unique identifier for the test entry. 
Environmental data table entry 620 contains transac- 
tion identifier 621 and a plurality of fields specifying 
test conditions 622-624, e.g. test temperature, 
applied voltages, identification of test fixture, etc. 
Extended failure information log entry 630 contains 
transaction identifier 631 and error code 632. Trans- 
action identifier 617 of card process result file entry 
610 is used as a key to access the corresponding 
environmental data table entry 620 and extended fail- 
ure information log entry 630 when test result field 616 
is 'Fair, as shown by the arrow in Fig. 6. Where the 
test result is 'Pass', no corresponding entries are 
made in environmental data file 602 and extended 
failure information log 603. Error code 632 comprises 
24-character major part 633 and 32-character minor 
part 634. Major part 633 identifies the basic failure 
symptoms, while minor part 634 identifies the condi- 
tions of the registers read from test pins. Minor part 
634 provides a more specific level of diagnosis, but is 
not always necessary. E.g., for certain diagnoses, the 
condition of the registers is undefined, and the minor 
part is probably not meaningful. Where two cards 
exhibit the same major and minor part error codes, it 
is highly probable that the error is caused by the same 
defect. Where two cards exhibit the same major part 
error code, but different minor part error codes, there 
is generally a reduced probability that the error is 
caused by the same defect. 

Repair action/defect databases 313 comprise 
two database files, a repair action file and a defect file. 
Entries in both files have identical fields. The repair 
action file contains an entry for each repair action 
taken by a test station. If subsequent testing of the 
card assembly establishes that the repair action cor- 
rected the defect, the entry in the repair action file is 
copied to the defect file. Thus, the defect file is a sub- 
set of the repair action file, containing only those diag- 
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noses/repair actions shown to be correct. The format 
of an entry in either file is shown in Fig. 7. Each entry 
701 comprises transaction identifier 710, card assem- 
bly part number 711, rework station identifier 712, 
rework station operator 713, defect quantity 714, 5 
defect code 715, part number of defective component 
716, defect location on card 717, side of card on which 
defect occurred 718, and time/date stamp 719. Defect 
quantity field 714 tracks the number of occurrences of 
a defect, which is usually one; in some cases, (e.g., 10 
"bent pin", "defective solder joint"), the defect may 
occur more than once with respect to a single compo- 
nent. 

Defect code databases contain information relat- 
ing each sub-object type to the possible defects that 15 
may be experienced with respect to the component. 
It comprises two files, sub-object type cross reference 
table 801 and defect code table 802, as shown in Fig. 
8. Sub-object type cross-reference table relates each 
sub-object type to the possible defect codes 20 
associated with a sub-object of that type. Each entry 
810 contains sub-object type identifier 811, and a 
plurality of flag fields 812-815 indicating whether the 
defect code associated with the field column applies 
to the sub-object type. Defect code table 802 contains 25 
more detailed information regarding each defect 
code. Each entry 820 is keyed by defect code number, 
and comprises defect code 821, text description 822, 
target defect rate 823, and text description for menu 
selection use by the repair cell 824. For example, in 30 
Fig. 8, flag field no. 24 contains "Y", indicating that 
defect code 24 is a valid defect code for sub-object 
type 310. The meaning of defect code 24 is explained 
in the keyed entry 820 in defect code table 802. 

Repair cell 300 makes use of two distinct expert 35 
diagnostic functions. The first level, which does not 
use diagnostic knowledge base 320, is a non- 
inferencing statistical analysis of past failures and 
subsequently successful repair actions. In the case of 
relatively common failures, this level of diagnosis 40 
often covers a sufficient number of instances to yield 
good diagnostic resolution and high 'hit' rates. While 
this type of analysis is very fast, it is limited to defects 
which have occurred in the past, preferably more than 
once. This system may make either a single diag nosis 45 
or several diagnoses for the same error condition. In 
cases where multiple diagnoses are produced, a 
statistical likelihood is included with each one. 

The second level of diagnosis is directed search 
of recommended analysis procedures, using rules 50 
contained in diagnostic knowledge base 320. This set 
of rules is established cooperatively by the design 
engineer and a knowledgeable test engineer. This set 
of rules can be accessed by repair cell 300 for use by 
expert system inference engine 304. In the preferred 55 
embodiment, inference engine 304 is an IBM 
Knowledge Director expert system inference engine, 
although other inference engines could be used. The 
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operator can invoke a consultation mode at will, cal- 
ling inference engine 304 to recommend actions 
based on the rules in knowledge base 320 when the 
operator needs guidance. In both consultation 
modes, the actual consultation session runs on local 
computer 114. 

The operation of the rework station according to 
the preferred embodiment is now described. Figure 9 
shows a block diagram of the major steps of the man- 
ufacturing environment in which the rework station 
operates. A block diagram of the major steps of oper- 
ation of the rework station itself is shown in Figure 10. 
In this environment, each card assembly passes 
through one or more stages of manufacture 901, 902, 
903, and at the conclusion thereof is subjected to a 
functional test 904. If the test reveals any failure 
symptoms, the test results are saved in a database 
905 and the card is sent to a queue to await rework 

906. When a rework station becomes available, the 
rework station diagnoses and repairs the problem 

907, and returns the card to functional test 904. If the 
card passes functional test, it proceeds to a packag- 
ing area 908, where it is packed and stored in inven- 
tory. In order to avoid infinite looping of an individual 
card between testing 904 and rework 907, a limit is 
placed on the number of times an individual card may 
be reworked. Therefore, immediately after testing, 
this limit is checked 909. If the limit is exceeded, the 
card is scrapped 910; otherwise it proceeds to save 
test results 905, await rework 906, and rework 907, as 
described above. Although three manufacturing 
stages following by a single test stage are shown, it 
should be understood that the number and placement 
of stages of each type is variable. 

Operation of the rework station is shown in Figure 
10. Operation begins when a card 101 which exhi- 
bited symptoms of failure arrives. The rework station 
operator first reads bar-code label 102 on the card 
with bar-code reader 1 1 3, at step 1 001 . The bar-code 
label tells repair cell 300 the serial number and part 
number of card assembly 101. In the preferred embo- 
diment, the manufacturing facility may be simul- 
taneously engaged in the manufacture of cards 
having different part numbers, but the rework station 
is generic, i.e., capable of repairing any type card. It 
is therefore necessary to identify the type of card 
being repaired to repair cell 300. 

Repair cell 300 responds to part and serial num- 
ber identification by requesting data over LAN 200 
from resource/database server 220, at step 1002. 
Repair cell 300 will request the test results and history 
of repair actions for the individual card under rework. 
Repair cell 300 may also request the card component 
file 400 and associated bitmaps for the part number 
of the card under rework, depending on whether or not 
these are already in storage on local computer 114. 
Resource/database server 220 responds at step 1 003 
by supplying the requested information. Server 220 
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will query test results databases 312 and repair 
action/defect databases 313 for all actions affecting 
the card under rework, and build a log for that card 
only, which is returned to repair cell 300. 

When card component file 400 and the bitmap 
images are available on local computer 114, graphical 
image procedure 301 constructs an image of the card 
for display to the operator at step 1004. Graphical 
image procedure 301 processes the list of sub-ob- 
jects in card component file 400 line by line, copying 
the specified bitmap image, in the orientation speci- 
fied, to the area described by the entries in sub-object 
extent fields 421-424. As each bitmap is copied, it 
may overlay all or a portion of a previous bitmap. 
Thus, an important additional parameter is hidden in 
the card component file; it is expressed by the sort 
order in which the sub-object descriptions appear. 
Components hidden under other components appear 
first in the list, and are subsequently covered by the 
bitmap images corresponding to components later in 
the list, just as the physical component would by cov- 
ered. For example, in the case of a card assembly, a 
component such as a socket or decoupling capacitor 
may be covered by another component. This ability to 
overlay components from the list ordering supports 
the capability to remove components from the graphi- 
cal image and reveal those that lie underneath. 

If the operator wishes to work with a hidden com- 
ponent, he may select a component for removal from 
the displayed image, to reveal those lying underneath 
at step 1 005. The operator selects a "peel off' function 
from a menu, and repair cell 300 responds by modify- 
ing the image. The selection of the component is 
made by pointing to the location of the components 
image on the screen with lightpen 1 1 3 or other cursor 
pointing device. In response to this selection, select 
decode procedure 302 determines the screen coordi- 
nates of the selected location, and maps this coordi- 
nate location to the component which contains the 
location within its rectangular extent area 503. If more 
than one component extent area includes the loca- 
tion, the most visible component (last active compo- 
nent on the list) is selected. Select decode procedure 
302 returns the identity of the selected sub-object. 
The image is modified by reconstructing that portion 
of it within the rectangular extent area 503 of the com- 
ponent being "peeled off". Since the entries in card 
component file 400 are ordered by physical level, it is 
only necessary to reconstruct the extent area using 
sub-object entries occurring before the selected sub- 
object in the list. 

Related to the "peel off" function is a fiip function, 
by which the operator can elect to flip the card image 
to its reverse side at step 1006. In many card 
assemblies, components are attached to both sides of 
the card, making it necessary to enable depiction and 
selection of components on either side. The operator 
may also select a "zoom" function at step 1 007, to 



enlarge crowded areas of the card assembly for 
easier viewing and selection of small components. In 
the case of either peel off, flip or zoom function, repair 
cell 300 returns to the main display menu after mod- 

5 ifying the image as requested. 

From the main display menu, the operator has 
several choices available. The operator may be able 
to diagnose the problem immediately by simple visual 
inspection or other means. The operator may also 

w invoke either of two expert system consultation 
modes to assist in diagnosing the problem. 

If the operator can diagnose the problem without 
on-line assistance from the expert system, he may 
immediately select a component to work with at step 

is 1008. The selection is made by pointing to the com- 
ponent with light pen 113 in the same manner as 
selecting a component to peel off. Select decode pro- 
cedure 302 determines the selected component, and 
returns the identity of the selected sub-object. The 

20 sub-object entry identifies the type of sub-object. 
Each type of sub-object is associated with a list of 
possible diagnoses/repair actions. Repair cell 300 
displays a menu of such diagnoses/repair actions 
applicable to the selected component. The operator 

25 then selects one of these actions with light pen 113. 

The operator may select either of two expert con- 
sultation modes. The first mode invokes a non- 
inferencing statistical analysis of past failures and 
subsequently successful repair actions at step 1009. 

30 Repair cell 300 queries test results databases 312 for 
all instances of the same or similar test symptoms, i.e. 
having same or similar error code 633. It then queries 
the defect file of repair action/defect databases 313 to 
determine which repair action was subsequently suc- 

35 cessful in resolving the defect. Finally, it queries the 
repair action file of repair action/defect databases 313 
to determine which repair actions have previously 
been performed on the individual card assembly 
under rework. Any repair actions already attempted 

40 on the card are rejected, and not presented to the 
operator. The remaining diagnoses/ repair actions 
are presented to the operator, along with the number 
of instances found. Two separate lists of diagnoses/repair 
actions are presented, one in which both major part 

45 633 and minor part 634 of error code 632 matched, 
and the other in which only major part 633 matched, 
with separate number of instances presented in each 
case. These lists are sorted in descending order of 
number of instances found. Generally, it will beexpec- 

so ted that the operator will prefer diagnoses from the 
more specific list (containing matches for both parts), 
but in the event that list contains no entries or its 
entries have a very small number of instances, the 
operator may elect a diagnosis from the less specific 

55 list. 

The second expert consultation mode at step 
1010 is a directed search of recommended analysis 
procedures. In cases where the failure syndrome has 
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not previously been seen, or only occurs rarely, a his- 
tory driven knowledge base used in the first consul- 
tation mode is of little assistance. It is in this situation 
that the second mode of knowledge base operation is 
most useful. This system is based upon a multi-way 5 
branching tree algorithm; a consultation session con- 
sists of asking the user increasingly specific 'ques- 
tions', and using this information to branch to the next 
lower level of detail. In this embodiment, repair cell 
300 highlights the component or components under 10 
scrutiny. By selecting any one component, repair cell 
300 displays 'questions' in the form of possible 
defects or actions required. The operator then verifies 
whether the defect exists or performs the action. In an 
additional embodiment, the repair cell application may 15 
be connected to a test fixture. These 'questions' may 
in some cases be routed directly to the tester for re- 
solution. An example would be a situation where the 
consultation session requires the application of 
additional test cases to make a proper determination 20 
of condition. In these cases, the repair cell issues the 
commands directly to the tester, allowing large por- 
tions of the consultation session to run 'hands off. 
The operator is only called upon when physical action 
is required (e.g. 'Replace Component') or when 25 
knowledge outside the domain of the system is 
required (e.g. "Has Adjustment 'A' been performed on 
this unit?"). 

The decision tree used by this system is 
developed cooperatively by the device designers and 30 
test engineers. The input knowledge for this process 
is a combination of the following factors. A fault tree 
analysis indicates how the device is likely to fail, 
based upon how it is designed and manufactured. The 
point of failure within the test sequence indicates what 35 
areas of device function have been proven oper- 
ational up to that point, what areas are yet to be pro- 
ven, and what area of function was this portion of the 
test designed to validate; it may also take into account 
prior repair actions to the card under rework. The his- 40 
torical analysis of previous similar designs indicates 
what areas can be expected to cause trouble, how 
have they failed in past designs, and what repair 
actions have been effective. Manufacturing process 
analysis indicates what fault types are likely to be con- 45 
tributed by the manufacturing processes and what 
failure syndromes they would generate. Since this 
decision tree is based in part on past history, it is 
expected that as the system gathers defect code stati- 
stics, the rules will be updated to reflect new so 
knowledge. 

When the operator has determined an approp- 
riate diagnosis/repair action, either by his own inspec- 
tion or in consultation with the system, he selects the 
action from among the alternatives displayed with 55 
light pen 113 at step 1011. This selection automati- 
cally causes an entry to be made in the repair action 
file of repair action/defect database 313 at step 1012. 
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No other action on the operator's part is required to 
create the database entry. The operator then per- 
forms the indicated repair action at step 1013. 

After the repair action is performed, the card 
assembly is again tested. This test may be performed 
at the rework station, or at a separate testing station. 
If the card now passes the test, the entry previously 
made in the repair action file is copied to the defect file 
of repair action/defect database 31 3. The card is then 
returned to the normal manufacturing stream. 

Messages to update the repair action/defect 
database are sent by the rework station or test station 
to resource/database server 220, which writes new 
information to storage. At the same time, defect moni- 
tor 224 monitors the frequency of confirmed defects. 
This monitor analyzes each new entry in the defect file 
of repair action/defect database 313 when it is added 
to the database. Based upon the stored target defect 
rate field 823 of defect code table 802, a determi- 
nation is made on a per event basis whether this 
observation is an indication that the process is going 
(or has already gone) outside its control limits. If a pro- 
cess control problem is detected, defect monitor 224 
sends a warning message to plant manager 216. 
Additionally, the appropriate process engineer is elec- 
tronically notified. In cases where the deviation repre- 
sents a quality exposure or safety hazard, the defect 
monitor may also notify the process equipment to halt. 
This latter ability is contingent upon the process 
equipment being designed to accept and react to such 
a message. A report generating program may also 
upon request retrieve data from repair action/ defect 
database to generate reports of defect rates for the 
plant or specific components, processes or work sta- 
tions. 

By making the repair cell the interface to the diag- 
nostic mechanism, the operator is no longer burdened 
with a separate data collection mechanism, and need 
not even be aware that his actions are gathering data. 
This can be a productivity gain as well as an aid to the 
completeness and accuracy of the collected data. The 
integration of a knowledge base interface perceptu- 
ally provides the operator with a single tool, encom- 
passing the testing, diagnosis, and repair of entities, 
with a 'built in' expert to provide guidance. The prim- 
arily graphical nature of the interchange between the 
operator and the system also aids the marginally 
fluent user by minimizing textual exchanges. 

Because the system is driven by selection of sub- 
objects and menu items, there is no confusion over 
what actions to 'tell' an entity to perform; each object 
informs the user of its capabilities upon its selection. 
This reversal of 'verb/object' commands to 'ob- 
ject/verb' selections largely eliminates the existence 
of messages of the form The object cannot perform 
the requested action'. Indeed, since the sub-object 
provides the user with a selection of actions which it 
is capable of performing, the user cannot select an 
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action that is not offered. This also helps overcome 
any potential 'jargon 0811161', where various objects 
might name the same action differently (e.g. 'Rep- 
lace', 'Repair*, 'Substitute', and 'New Part'). 

Since the characteristics of the sub-objects is 
contained within each entry, new systems can 
be 'grown' by inheriting some or many of the sub-ob- 
ject types from one or many other systems. The visual 
representation (bitmap) of the sub-object has 
intentionally been divorced from its Type'. Thus, one 
sub-object type can be represented by different bit- 
maps in different instances of the sub-object. For 
example, a sub-object of type 'Screw' can support 
images of many different sizes and shapes of 'Screw', 
so long as their capabilities and properties match. 
Conversely, a single bitmap may be used by sub-ob- 
jects of different type. For example, the same compo- 
nent may have different failure modes, depending on 
the process used to attach the component to the card. 
In such a case, there will be different sub-object types 
for the component, depending on the process used. 
However, the component will still look the same, so its 
bitmap image will be the same in either case. As a 
result, the number of sub-object types and bitmaps 
which must be produced is greatly reduced. This also 
reduces the burden of creating new instances of exist- 
ing sub-object types. 

In the preferred embodiment, repair cell 300 is but 
a part of a comprehensive computer integrated man- 
ufacturing system. In addition to supporting repair cell 
300, this comprehensive system supports manufac- 
turing stations, test stations, plant monitoring, etc. 
Applications running on these stations could include 
more traditional CIM applications, such as material 
requirements planning and workstation scheduling. It 
can also serve as a platform for an integrated set of 
general use operator tools, such as notebook, calen- 
dar, timecard and labor tracking, electronic mail, etc. 
The individual workstations are coupled by local area 
network 200 to resource/database server functions, 
which are available to all work stations. This supports 
a cooperative processing paradigm, with the majority 
of applications actually running at the work station 
level. A distinct advantage to this arrangement is the 
reduced loading on the servers, since additional work 
stations bring with them additional processing power. 
However, in a alternative embodiment, a repair cell in 
accordance with this invention could operate without 
being attached to a comprehensive CIM system. For 
example, a rework station and test station could be 
one and the same, driven by a single local computer 
which stores databases required by the repair cell 
application. The rework station might alternatively be 
connected to a local area network of similar stations 
and a database server, without any connection to 
manufacturing stations. 

In the preferred embodiment, the various work 
stations are coupled together via a local area network, 



permitting distributed processing. In an alternative 
embodiment, the work stations could be simple non- 
programmable terminals, connected to a central 
mainframe computer which controls access to the 
5 database and supports multiple users simul- 
taneously. 

In the preferred embodiment, the primary means 
of interaction with the repair cell is via a cursor point- 
ing device such as a light pen. Generally, the operator 
10 is not required to use a keyboard or other textual input 
device. This not only speeds and simplifies user 
interaction, but improves the accuracy of the pas- 
sively collected data. This feature is enhanced 
through the ancillary application of a bar code scan- 
ts ner. However, it should be understood that the cursor 
pointing device is not essential to the operation of the 
repair cell, and in an alternative embodiment the 
operator could enter all data via a keyboard. 

In the preferred embodiment, the representation 
20 of card assembly 101 on display 110 is a graphical 
image, which resembles the card in visual appear- 
ance. In an alternative embodiment, any represen- 
tation which would allow the operator to identify and 
select components could be used. For example, non- 
25 graphics characters could be used as component 
labels in approximately the same location as the com- 
ponents themselves, the components being selected 
by pointing to the labels. A representation could even 
be as simple as a list of components. 
30 In the preferred embodiment described above, 

the article being reworked is an electronic circuit card 
assembly. Such assemblies lend themselves to two- 
dimensional graphical representation on a computer 
display. Since circuit cards may have components on 
35 both sides, a "flip" function is necessary to represent 
components on the opposite side. Beyond this "flip" 
function, there is no need for more complex three- 
dimensional representation. Many other articles of 
manufacture can be represented in two-dimensions 
40 as described above. It is not necessary that the article 
itself have no depth, but only that a two-dimensional 
representation can be constructed which is suffi- 
ciently recognizable for an operator to be able to iden- 
tify components by pointing to them on the screen. 
45 However, in an alternative embodiment, this invention 
could be applied to more complex representations in 
three or more dimensions. For example, in addition to 
the four extent fields 421-424, two additional fields 
could be provided for depth, additional bitmaps could 
so be provided for rotating the image, etc. In the alterna- 
tive, the article could be represented as a series of 
vectors, enabling rotating the image about an arbit- 
rary axis. 

55 

Claims 

1. A computer integrated manufacturing rework 

10 
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apparatus for supporting rework of a manufac- 
tured article, said article comprising a plurality of 
components, said apparatus comprising: 
means for storing and retrieving unique compo- 
nent descriptive information for each of said 5 
plurality of components, said unique component 
descriptive information identifying a list of poss- 
ible defect diagnoses associated with said com- 
ponent; 

means for displaying a representation of said 10 
manufactured article; 

means, interactive with said display means, for 
selecting a component of said manufactured arti- 
cle; and 

means, responsive to said means for selecting a 15 
component, for displaying said list of possible 
defect diagnoses associated with said selected 
component. 

2. The computer integrated manufacturing rework 20 
apparatus of claim 1, further comprising expert 
system consultation means for invoking an expert 
system to recommend one of said possible defect 
diagnoses. 

25 

3. The computer integrated manufacturing rework 
apparatus of claim 2, wherein said expert system 
consultation means comprises: 

a knowledge base of expert system production 
rules; and 30 
an inference engine capable of applying input 
data to said knowledge base to draw inferences. 

4. The computer integrated manufacturing rework 
apparatus of anyone of claims 1-3, 35 
wherein said unique component descriptive infor- 
mation comprises information for constructing a 
graphical representation of said component; and 
wherein said means for displaying a represen- 
tation of said manufactured article comprises 40 
means for constructing an image of said article 
from said information for constructing a graphical 
representation of each component of said article. 

5. The computer integrated manufacturing rework 45 
apparatus of claim 4, further comprising means, 
responsive to said means for selecting a compo- 
nent, for removing said component from the dis- 
played image representation of said 
manufactured article, and substituting therefor an 50 
image of components that would be visible 
beneath the selected component if said selected 
component were physically removed from the 
article. 

55 

6. A computer integrated manufacturing rework 
apparatus for supporting rework of a manufac- 
tured article comprising: 
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means for storing and retrieving one or more sets 
of failure symptoms which may occur with respect 
to said manufactured article; 
means for storing and retrieving one or more sets 
of possible defect diagnoses of said manufac- 
tured article, wherein each of said sets of failure 
symptoms is associated with one of said sets of 
possible defect diagnoses; 
failure identification means, for identifying a set of 
failure symptoms associated with an individual 
manufactured article; and 

display means, responsive to said failure identifi- 
cation means, for displaying said set of possible 
defect diagnoses associated with said set of fail- 
ure symptoms associated with the individual 
manufactured article. 

7. The computer integrated manufacturing rework 
apparatus of claim 6, wherein said display means 
further displays, with respect to each of a plurality 
of said possible defect diagnoses, a represen- 
tation of the probability that said possible defect 
diagnosis is correct 

8. The computer integrated manufacturing rework 
apparatus of claim 7, further comprising: 
means for storing and retrieving, for each of said 
possible defect diagnoses, a quantity represent- 
ing the frequency of occurrence of said possible 
defect diagnosis; and 

means for calculating said representation of the 
probability that said possible defect diagnosis is 
correct, wherein said probability is calculated 
from said quantity representing the frequency of 
occurrence of said possible defect diagnosis. 

9. The computer integrated manufacturing rework 
apparatus of claim 8, further comprising: 
means, interactive with said display means, for 
selecting one of said possible defect diagnosis for 
execution of a corresponding repair action; 
repair action result feedback means for identify- 
ing whether said repair action, when executed, 
corrected said set of failure symptoms; and 
defect tracking means, responsive to said repair 
action result feedback means, for incrementing 
said quantity representing the frequency of 
occurrence of said defect diagnosis if said repair 
action, when executed, corrected said set of fail- 
ure symptoms. 

10. The computer integrated manufacturing rework 
apparatus of claim 9, further comprising defect 
rate monitoring means, responsive to said defect 
tracking means, for determining when said quan- 
tity representing the frequency of occurrence of 
said defect diagnosis is incremented beyond a 
predetermined level and for taking remedial 
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action in response thereto. 

11. A method of using a computer coupled to a com- 
puter display to support rework of a manufactured 
article, comprising the steps of: s 
storing one or more sets of failure symptoms 
which may occur with respect to said manufac- 
tured article; 

storing one or more sets of possible defect diag- 
noses of said manufactured article, wherein each 10 
of said sets of failure symptoms is associated with 
one of said sets of possible defect diagnoses; 
identifying a set of failure symptoms associated 
withan individual manufactured article; 
retrieving the set of possible defect diagnoses 15 
associated with said set of failure symptoms 
associated with said individual manufactured arti- 
cle; and 

displaying on said computer display said set of 
possible defect diagnoses associated with said 20 
set of failure symptoms associated with the indi- 
vidual manufactured article. 

12. The method of claim 11, further comprising the 
steps of: 25 
determining, with respect to each defect diag- 
nosis in said set of possible defect diagnoses dis- 
played on said computer display, a 
representation of the probability that said defect 
diagnosis is correct; and 30 
displaying on said computer display each of said 
representations of the probability that a defect 
diagnosis is correct. 

13. The method of claim 12, wherein said step of 35 
determining, with respect to each defect diag- 
nosis, a representation of the probability that said 
defect diagnosis is correct, comprises the steps 

of: 

storing, for each of said possible defect diag- 40 
noses, a quantity representing the frequency of 
occurrence of said possible defect diagnosis; and 
deriving said representation of the probability that 
said possible defect diagnosis is correct from said 
quantity representing the frequency of occurr- 45 
ence of said possible defect diagnosis. 

14. The method of claim 13, further comprising the 
steps of: 

selecting one of said possible defectdiagnosis for so 
execution of a corresponding repair action; 
executing said repair action; 
identifying whether said repair action, when exec- 
uted, corrected said set of failure symptoms; and 
incrementing said quantity representing the fre- 55 
quency of occurrence of said defect diagnosis if 
said repair action, when executed, corrected said 
set of failure symptoms. 



15. The method of claim 14, further comprising the 
steps of; 

determining when said quantity representing the 
frequency of occurrence of said defect diagnosis 
is incremented beyond a predetermined level; 
and 

taking remedial action in response thereto. 

16. The method of claim 11, wherein each manufac- 
tured article contains a unique identifier, and said 
method further comprises the step of uniquely 
identifying said individual manufactured article to 
said computer. 

17. The method of claim 16, wherein said step of 
uniquely identifying said individual manufactured 
article to said computer comprises reading a 
unique identifier contained on a bar-code label on 
the card with a bar-code reader input device. 

18. The method of claim 16, wherein said step of 
identifying a set of failure symptoms comprises 
the steps of: 

inputting said set of failure symptoms and said 
unique identifier from a testing station; 
storing said set of failure symptoms with said 
unique identifier; and 

retrieving said set of failure symptoms in res- 
ponse to said step of uniquely identifying said 
individual manufactured article. 

19. The method of claim 18, wherein said step of 
uniquely identifying said individual manufactured 
article to said computer comprises reading a 
unique identifier contained on a bar-code label on 
the card with a bar-code reader input device. 

20. The method of claim 12, further comprising the 
steps of: 

determining, for each of said sets of failure 
symptoms which may occur with respect to said 
manufactured article, a set of quantities repre- 
senting the frequency of occurrence of a set of 
possible defect diagnoses when the set of failure 
symptoms is present; and 
deriving said representation of the probability that 
said possible defect diagnosis is correct, wherein 
said representation is derived from the quantity in 
said set of quantities representing the frequency 
of occurrence of said possible defect diagnosis. 

21. The method of claim 20, wherein said step of 
determining a set of quantities representing the 
frequency of occurrence of a set of possible 
defect diagnoses comprises the steps of: 
storing a plurality of sets of failure symptoms gen- 
erated by testing individual manufactured arti- 
cles; 
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storing, for each of said set of failure symptoms, 
a defect diagnosis associated with a repair action 
which subsequently corrected said set of failure 
symptoms; and 

deriving said set of quantities representing the 5 
frequencies of occurrence of a set of possible 
defect diagnoses from said stored sets of failure 
symptoms and defect diagnoses associated with 
repair actions with subsequently corrected the 
failure symptoms. 10 

22. The method of claim 21, further comprising the 
steps of: 

selecting one of said possible defect d iagnosis for 
execution of a corresponding repair action; 15 
identifying whether said repair action, when exec- 
uted, corrected said set of failure symptoms; and 
automatically storing said defect diagnosis in a 
database of defect diagnoses determined to have 
been correct, if said repair action was determined 20 
to have been correct. 
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